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ABSTRACT 


This document summarizes a study of the AFICCS display system. 
Currently available AFICCS display features are reviewed and 
deficiencies, or lack of existence, are noted. Recommendations 
for improvements are segregated into two categories; near-term 
and long-range. 
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SECTION I 
INTRODUCTION 


This document summarizes a study of the AFICCS display system. 
Currently available AFICCS display features are reviewed and 
deficiencies, or lack of existence, are noted. Recommendations 
for improvements are segregated into two categories; near-term 
and long-range. 

The approaching advent of system phaseover from IBM 1410 to 
third generation precludes any serious thought of redesigning 
the 1410/BR-90 peculiar display software. Near-term recommendations 
for AFICCS display software improvements center on eliminating 
deficiencies of the e xisting system and implementing additional 
features designed to increase operational and functional effective¬ 
ness . 


Long-range recommendations are not influenced or biased by 
time restrictions and stress an orderly process of system design 
and definition. 

The majority of techniques and methods recommended for 
implementation are based on the results of programming experiments 
conducted at the AFICCS Support Facility. 
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SECTION II 

AFICCS DISPLAY SYSTEM 


HISTORY 

CRT console display devices evolved from early attempts to 
overcome restrictions associated with lineprinters on obtaining * 

quick computer output and response. Initial forms of CRT display 
devices were laboratory oscilloscopes, used primarily as auxiliary 
output devices to display curves and graphs. The early 1 CRT- 
console* increased in sophistication with the introduction of data 
input components. The initial type of input device attached to 
CRT consoles was the light-gun; the resultant combination providing 
the first example of an interactive display station. 

Interactive display devices (and techniques) distinguish 
themselves from conventional input/output devices by providing 
for rapid man/machine interaction; the highest level of this 
interaction being a continuous man/machine dialog. A further 
significant difference is provided by the ability of display 
devices to rapidly represent the same data in various formats 
(i.e., numeric data may be represented graphically). 

A major deterrent to using displays was the amount of time wasted 
by the CPU waiting for operator responses. The only effective way 
of interactive processing is to share the CPU among a number of 
display consoles or among different tasks. The introduction of 
third generation equipment with operating systems directed to 
time sharing and multiprogramming has reduced this problem con- 
siderably. 

A further approach to reduce ’system suspense time* caused 
by display utilization was the introduction of small display 
processors (computers) dedicated to the interactive display consoles 
and operating in parallel with the CPU. It is the function of this 
small processor to free the CPU from performing display specific 
operations such as frame formatting, CRT refreshing and function 
key interpretation. The advantage of this type of operation, 
called distributed processing, is the reduction of the number of 
display interrupts in the CPU and referrals between the CPU and 
the display console. Naturally, nothing is gained if the CPU 
does not operate in a multi-task environment. 
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The functional effectiveness of any display system is bounded 
by the versatility of its software. The usefulness of console 
displays can be greatly enhanced by compiler-type display languages 
permitting graphics manipulation through symbolic operands. The 
lack of such software is analogous to producing computer programs 
solely with machine language. 

SYSTEM COMPONENTS 

Hardware 


The standard equipment components for each AFICCS facility are; 

a) One to six AN/FYQ-45 f s, better known as BR-90 f s, functioning 
as the display consoles; 

b) One AN/FYQ-38, better known as a CIB (Computer Interface 
Buffer), functioning as the communication link between 
the display consoles and the CPU (Central Processing 
Unit); 

c) One IBM 1410 Data Processing System (40K of core memory, 
no priority alert feature), functioning as the CPU; and 

d) Various auxiliary I/O and storage devices, including tape 
units and disk, attached to the CPU. 

The AN/FYQ-45 (BR-90) is a highly sophisticated display station. 
Its features include graphic capabilities (lines, circles, points), 
two function keyboards, alphameric keyboard, cursor, lightpencil 
and a background slide projection system. The BR-90 is driven by 
its own dedicated processor with a memory capacity of 8192 12-bit 
words. The processor has a repertoire of 16 instructions, which 
permit the control of all console features including interrupt 
processing and CRT frame refreshing. 

The CIB provides the communication link between the CPU and up 
to six BR-90 display consoles. The CPU treats the CIB as a tape 
unit and communicates with the display consoles through tape read 
and write commands. While the CPU may interrupt a BR-90 console 
processor at any time, the reverse is not true. The CPU must test 
an attention request bit to determine if a display unit requires 
service. 
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Software 


The AFICCS display software is comprised of three sets of 
program packages. The Bunker-Ramo supplied N-mode program controls 
the operation of the dedicated display processor, and as such, 

exercises control over all features of a display station. The # 

BR-90 resident N-mode program permits the operation of a display 
console either in an off-line fashion or on-line in conjunction 

with the CPU. „ 

The IBM supplied Computer Interface Program (CIP) package, 
in conjunction with the N-mode program, constitutes an applications 
programming system. These 1410 resident programs essentially 
provide for buffer management and CPU/display console interface. 

They may be regarded as utility programs to be utilized by user 
generated display programs to exercise operational control over the 
display system. 

User-capability programs constitute the third set of display 
programs. These are functional programs, written with the aid of 
the above programming system, to solve particular problems or form 
a broader set of applications programs which may be used by persons 
not familiar with the peculiarities of the display system. The 
QUEST II Overlay Capability is such an applications program. 

GENERAL PROBLEMS 

The limited utilization of the display consoles has been the # 

immediate observation of any study of the AFICCS system. While 
this situation results from lack of a wide range of display oriented 
user-capability programs, the fundamental problem source lies at 
the core of the AFICCS system and its basic display software. These 
problems fall into two categories: 

a) The standard AFICCS system does not provide an environment 
suitable for the support of interactive displays; and 

b) The display software (CIP/N-mode), while satisfying some 
of the requirements for interactive display operations, is 
seriously deficient in terms of graphic utilities and 
exploiting the available features of the BR-90. 

An inherent trait of display systems, interactive or otherwise, 
is their unique form of CPU utilization. Since the next CPU action 
generally is in response to an operator reaction to the previous 
display output, considerable CPU idle time can be incurred while 
the display console operator decides on his next move. In facilities 
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performing large volumes of serial and batched processing, this 
manner of display operation can be prohibitive. Precisely this 
problem is incurred by AFICCS when operating in the display mode; 
the CPU is dedicated to the displays even at periods of console 
inactivity. Further, the distributed processing potential of the 
BR-90 resident display processor is not used, for there is nothing 
to process in parallel. 

Any effective display software must provide methods and 
techniques for the efficient construction, modification and 
maintenance of display frames and strings. AFICCS provides for 
frame construction in disk buffers; however, the available methods 
for textual frame construction can be classified as marginal, while 
in the case of graphic strings the programmer is completely on his 
own without any aids. 

The following sections of this document present recommendations 
for more efficient use of the available display components of the 
AFICCS system. Included for consideration are various categories 
of user-capability programs intended to extend the interplay with 
operational requirements of the system. Near-term recommendations 
employ available software whenever possible and provide methods 
and techniques through which the impact of previously mentioned 
problems may be reduced or overcome. 
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SECTION III 

NEAR-TERM RECOMMENDATIONS 


CAPABILITY PROGRAMS 

The primary objective of an interactive display system is 
mission oriented toward the fulfillment of the system*s operational 
requirements. In a command and control environment, such as AFICCS, 
a display system must interact with the data base to provide a 
variety of timely services. These may include the quick retrieval 
of data items, dynamic maintenance of data structures, representa¬ 
tion of reports in various formats, pictorial representation of 
complex dynamic situations and many others. 

While some AFICCS commands are currently undertaking serious 
efforts to supplement their operational capabilities with displays, 
the standard system makes very limited use of the BR-90. The 
following areas of display application are suggested for implementa¬ 
tion. In most cases, prototypes or models of these capabilities 
have been implemented at the AFICCS Support Facility. 

(The implementation of these suggested capabilities should be 
conducted in such a fashior to ensure their compatibility with a 
multiprogramming environment as described in later sections). 

D ata Base Management 

The ability to interact online with a data base to perform 
functions such as retrieval, exception updating and browsing is 
desirable. While some display retrieval capabilities already 
exist (QUEST II Overlay and Query Language) , their modification 
and refinement is necessary for efficient and meaningful operation. 

Information Retrieval 


The QUEST II Overlay capability furnishes extensive retrieval 
and computational features for AFICCS serial tape files. Utilization 
of this feature is minimal because of its great CPU time require¬ 
ment. For more efficient operations, the following changes are 
mandatory: 

a) Construction of cues must be performed in a distributed 
processing mode. This means that the CPU will not be 

dedicated while the operator constructs the multitude * 

of lengthy job control cues, but continues with the 
processing of an independent task. 
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b) When actual retrieval processing begins (following 

completion of cues) , communication with the CIB should 
be reduced or eliminated. Currently, the retrieval 
programs continuously request the BR-90 status, apparently 
to test for CANCEL/DEACTIVATE requests. While this 
operation is not only time consuming, it also forces the 
dedication of the display station in instances where this 
is no longer required. (Example: QUEST II Overlay is 
used for tape sorting; no output appears on the display 
console. ) 

File Maintenance 


On-line file maintenance is exceptionally well suited for the 
relatively infrequent updating of static entries as appear with 
AFICCS parallel files. Capability programs of this category 
currently exist at the AFICCS Support Facility! >2 # They permit 
on-line file generation, modification and deletion. 

The ability to browse a data set, file or table should be considered. 
This would allow the leisurely examination of file entries selected 
by parameter specifications; thus, providing tools to ensure the over¬ 
all data quality and reliability. Operating in a multi-task environ¬ 
ment is mandatory for a capability of this nature. A serial file 
’browsing* capability exists at the AFICCS Support Facility^. 


■SlTR-573, Dynamic Data Integration: Design Specifications for AFICCS 
File Manipulative Functions. 

^MTR-757, The AFICCS Serial File Maintenance Capability. 


wP-2576, A BR-90 Display Experiment in Distributed Processing. 
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Report Generation 


The extensive textual and graphic features of the BR-90 
display console are particularly suitable for the generation of a 
wide variety of reports. These may range from textual console 
query responses to more sophisticated graphic representations of 
numeric data. 

G raphic Data Representation 

Complex numeric data relationships are understood most rapidly 
if they are described in pictorial form. Consequently, capability 
programs which permit the graphic representation of numeric data 
are required. Capabilities of this category should be able to 
construct, on selective qualification of input data, comparative 
graphs, plots, scattergrams, histograms and other representations 
which compare data items against their environment. Graphing 
programs should produce the?r output against any (predefined) scale 
and should Drovide some statistical analysis features. 

A display program for graphic data representation has been 
produced at the AFICCS Support Facility and is fully operational. 

A more detailed summary of this capability is presented in Appendix A. 

B riefing Aid 

Use of the BR-90 as a briefing presentation aid should be 
considered. To ensure the continuity of such a briefing, all of 
its display frames should be prepared in advance and prestored on 
the disk. This approach is essential if it is desired to include 
displays generated by relatively slow retrieval programs. 

The following types of displays render themselves applicable 
for inclusion in stored briefings: 

a) Manually prepared displays; 

b) Display responses to Query programs, such as QUEST II 
or Query Language; 

c) Graphic representations of numeric data; and 

d) Geographic display with background map and superimposed 
CRT data. 
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Essentially, two items are required for the implementation of 
these briefing aids: 

a) Utility routines callable by retrieval programs 

to save CRT images and associate projector control 
information on disk; and 

b) A briefing control program to retrieve saved displays 
via a directory. 

Dynamic Situation Displays 

One of the prime operational functions of AFICCS is the 
monitoring of constantly changing resources. Capability programs 
exist for status of force evaluation, mission and exercise planning, 
and a variety of other dynamic, mission-oriented tasks. The 
application of the BR-90, as a truly interactive display device, 
should be considered for some of these tasks for the following 
reasons: 

a) Geographic displays, generated with background maps and 
superimposed CRT information, provide quick understanding 
of tactical environments and problems; 

b) The display console provides the tools to call for 
additional data pertaining to a given situation; and 

c) The course of an exercise or simulation can be affected 
dynamically by timely command interaction with the 

system. 

4 

For implementation of ’background 1 map capabilities, techniques 
are required which correlate map coordinates with CRT coordinates. 
Appendix B presents mathematical methods to achieve this conversion 
for the projections of the standard AFICCS map slides (Mercator 
Conformal Cylindrical and Polar Stereographic). 

A model of a dynamic situation display, involving the allocation 
and monitoring of mobile resources (tanks, helicopters and troops) 
is presented in MTR-754. While this model pertains to a limited 
tactical environment, it is representative of this type of display 
utilization. 
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Utilizing the background projector. 
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Summary 


Each of the above areas in display application was presented 
to stimulate interest in enlarging the set of display associated 
capabilities within AFICCS. While they appear under the classifica¬ 
tion of 'near-term 1 improvements, it is not to be implied that they 
all should be implemented within the remaining life of the 1410 
AFICCS system, for obviously, neither the time nor the resources 
exist. 

SOFTWARE TECHNIQUES 

Section II of this document outlined serious deficiencies 
of the AFICCS display software. Software techniques designed to 
overcome these deficiencies and improve the overall efficiency of 
the AFICCS/1410/BR-90 display system are now presented. The 
recommendations stress the retention and application of existing 
software whenever possible. 

Distributed Processing Techniques 

Extensive display usage in AFICCS is only feasible if the 
forced dedication of the CPU during display operations is eliminated. 
CPU dedication requirements resulted from the absence of an automatic 
interrupt feature in the 1410, whereby the BR-90 processor could 
interrupt the 1410 whenever it required attention. As it stands, 
the 1410 may interrupt the BR-90, but the converse is not true. 
Consequently, the 1410 must either continuously or periodically 
perform a programmed status test of an attention request indicator 
in the CIB. As the display software is implemented, this test is 
performed continuously whenever the CPU is anticipating a BR-90 
request, thus dedicating the CPU and inhibiting the potential 
processing of any secondary tasks. 

The software approach presented to eliminate dedication of 
the CPU involves the following principles: 

a) The CIB attention request indicator is tested only 
periodically; 

b) The freed CPU time is used for secondary or background 
processing; hence, some type of time-sharing control 
is required; and 

c) Distributed processing techniques are applied to reduce 
CPU/display interaction and free additional CPU time. 
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While initially this appears to be a formidable undertaking, 
sufficient system structure and components already exist within 
AFICCS to allow circumvention of prohibitive redesign and reprogramming 

Programmed Interrupt Test 

The periodic testing of the CIB request indicator can be 
included in one of the heavily used utility and control routines, 
such as DSKACC or COPS. In this fashion, the programmed interrupt 
feature is available every time the disk is addressed or COPS is 
called. During standard AFICCS operations, these routines are 
called sufficiently often to provide a satisfactory frequency of 
interrupt tests. 

Time Sharing Techniques 

The above programmed interrupt test, by itself, provides no 
advantages over the existing system. A feature must be made available 
which permits useful employment of the freed processor time. 

AFICCS already provides for the overlaying of program levels 
in core; the COPS routine saves existing core images in disk buffers, 
loads higher level routines to be executed and consequently restores 
the old program from the disk buffer. This feature can serve as 
the basis for a time-sharing environment within AFICCS. MITRE 
WP-2241, A Way to Time Share Within AFICCS, describes three techniques 
of employing COPS for program buffer management in a multi-task 
environment. All three of these techniques conform to the following 
fundamental principles: 

a) A periodic, programmed status test determines if the 
display console requires service; 

b) If a service request is encountered and the background 
(non-display) job is currently in CPU core, the core 
image is saved on a disk buffer and the display program 
is loaded; 

c) After the display program completes its service, the 
background job is restored from disk and resumes control; and 

d) If no display request is detected in consequent tests, 

the background job retains control; otherwise, the program 
swapping cycle repeats. 

A disadvantage of this technique is the high processing 
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overhead^ incurred by repeated buffer exchanges. An alternate 
solution would allow for the partitioning of core for two programs, 
the foreground and background programs. In this fashion, no buffer 
exchange is required; only a jump in program control. 

Distributed Processing 

Time-sharing methods, as discussed in the preceeding paragraphs, 
provide for meaningful usage of CPU time which otherwise would be 
lost while waiting for operator responses from the display station. 
Additional savings in CPU processing time may be obtained by 
employing the display resident processor more efficiently through 
distributed processing techniques. The objective of distributive 
processing (within AFICCS) is to decrease the number of data and 
attention request referrals between the CPU and the display 
processor, and consequently to increase the amount of CPU time 
available for background* processing. This objective can be 
obtained in AFICCS by full utilization of the programmable BR-90 
resident computer. 

Certain categories of display oriented processing, which are 
performed by the CPU in the current AFICCS system can easily be 
designated to the display processor. Coupled with more ambitious 
buffer management techniques, it is conceivable to operate the 
BR-90 in a semi-off line fashion, referring back to the CPU only 
if a (large) data buffer has been exhausted. In the interim, the 
CPU is free to do something else. Distributed processing techniques 
discussed in the succeeding paragraphs center on the following 
principles: 

a) The modular design of the N-mode program provides a 
basis for the inclusion of specific user display programs 
within N-mode. Assembly programs exist to facilitate 
the coding and assembly of such subprograms; 

b) The usage of the CIP programs is optional; the 1410 
capability programs may contain the necessary code to 
achieve display interface; and 

c) CPU/display referrals are further reduced through 
application of buffer management techniques. 

Display Processor Programming . The BR-90 display processor 
has a repertoire of 16 instructions, including arithmetical, 
logical (shifting and merging) , control (branching) and I/O 
operations. Its core memory capacity is 8192, 12 bit words; a 
4096 word region of the core may contain executable programs, the 

(3) 


WP-2576, A BR-90 Display Experiment in Distributed Processing. 





other 4096 words can be used as a storage or display buffer area. 

As such, it provides the potential to perform a wide variety of 
display computation. 

In the AFICCS display system, N-mode is the sole program to 
operate from the display processor. N-mode consists of a set of 
standard non-functional utility routines and exercises control 
over all components of the display console, including the interrupt, 
input/output and refresh features. A review of the program has 
shown that it is organized modularly permitting the replacement 
of program sections (not pertaining to some applications) with 
any desired routines. It is therefore suggested that N-mode be 
used as a basis for the implementation of additional BR-90 routines. 
The selective retention of any desired control features of the 
N-mode program is a major advantage of this approach. 

MITRE WP-2535, The AFICCS BR-90 Display Software, provides 
a rather detailed description of the N-mode program and presents 
specific programming techniques for its modification and extension. 

Currently, two assembly programs^’^ exist which permit the 
writing of any desired display programs. 

CPU/BR-90 Software Interface . CPU core requirements for 
display interface may be relaxed by incorporating the necessary 
code directly in the capability program, instead of calling the 
CIP programs. An additional advantage gained in this case is a 
reduction in the number of COPS calls. A disadvantage, however, 
is the cumbersome bit construction of the control codes required 
for communication with the N-mode programs. (The implementation 
of small control subroutines would decrease this disadvantage). 

Buffer Management 

Buffer management is of extreme importance in the design and 
implementation of interactive display systems. Efficient buffering 
techniques are necessary to utilize the BR-90 display processor to 
its fullest extent. 


^MTR-597, BR-90 Assembly Program — BRASS. 
The Program EZY, produced by Bunker-Ramo. 
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The following buffer management techniques, designed to enhance 
the distributed processing potential of the AFICCS display software, 
are recommended for near-term implementation: 

a) Compression of display frames through dense polystrings; and 

b) Utilization of projector slides as a static storage medium. 

Display Frame Compression 

The existing software provides for the displaying of textual 
and graphic frames from disk buffers. Individual frames are 
associated with distinct relative records of a Symbolic Disk 
Address (SDA) and a separate CPU referral is required for each 
frame to be displayed. Each textual frame is generated from a 
single message string? which requires one cell of BR-90 core memory 
for every character position on the display screen. Consequently, 
each text message requires 2820 words of core. Since it is not 
conceivable that all available screen character positions will be 
used for any single textual display, there is no requirement for 
a fixed length display message string. A better approach, for the 
sake of less storage requirements, would be the deletion of sequences 
of successive blanks from the display message. The correct 
character position of the next non-blank segment is specified by 
separate x,y coordinates. 

Essentially, this process involves the conversion of a single 
text string into a (graphic) polystring message composed of a 
number of short text strings. The resultant saving in display 
core storage may be used for additional display polystrings to 
permit the displaying of successive frames without further reference 
to the CPU. 

g 

Experimental observations with textual polystrings have 
verified average core savings of 80 percent. A discussion of text 
format analysis and coordinate conversion techniques for text 
strings is presented in MITRE MTR-754, Display Software Techniques 
for AFICCS. 


A text message string consists of a pair of x,y screen coordinates, 
the actual message text and an end of message symbol. Detailed 
explanation of display message strings is found in Programming 
Reference Manual for Message Console AN/FYQ-45, Bunker-Ramo Corporation. 

g 

The experiments showed that greatest savings was obtained with the 
deletion of 'blank' sequences of length greater or equal to 3 
(blank characters). 
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Software components required for implementation and usage of 
this frame compression feature include: 

a) CPU routines to convert (textual) monostrings into graphic 
polystrings. More than one frame should be stored on 

one referral buffer to decrease CPU/display communications 
(this requires frame directories); and 

b) Display processor routines to provide for the orderly 
sequential displaying of frames obtained in batched 
transmission. 

While the pieceding discussion centers primarily on textual 
displays, it is recommended that the same multi-frame buffering 
techniques are applied to graphic display frames. 

S lide Data 

Slides of the BR-90 background projector may be employed as 
a secondary storage medium for static text data. The objective is 
again to minimize the number of CPU/display referrals. 

Data elements on slides become recognizable for internal 
machine-processing by associating them with a CRT superimposed 
raster of points. In this fashion, a one-to-one correspondence 
is established between distinct slide data items and light pencil 
sensitive points, so that a unique data item is identified if a 
particular raster point is selected by light pencil. A data item 
recorded on a slide can be uniquely identified as a consequence of 
a light pencil activation by the following criteria: 

a) Current magazine number; 

b) Current slide number; and 

c) Core location of 1 light-penciled 1 element (permits 
identification of x,y coordinates of T hit f raster point). 

These items are made available to the CPU, which in turn, performs 
any necessary decoding, via tables and directories, to obtain the 
required data item. Naturally, this process can also be performed 
in reverse, so that the CPU can identify a unique slide data item 
for the viewer by blinking the associated raster point. 

The advantage gain by this approach is the ability to transmit 
textual information in a very compactly coded form, freeing additional 
core memory for other processing. 
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G raphic Facilities 


The lack of suitable graphic utility programs to aid in the 
construction and maintenance of graphic displays was discussed in 
Section II. The futile construction of graphic display strings 
through bit manipulation in the 1410 can deter the most ambitious 
undertaking. 

The BR-90 assembly language offers more readily usable bit 
manipulation commands including macro operations to generate display 
items such as circles, vectors, and alphameric strings. It is 
therefore recommended that, whenever possible, any generation and 
formatting of display strings be performed in the BR-90 processor. 
This approach does not substitute for a well designed compiler-type 
display language; however, the implementation of such a feature can 
not be considered seriously as a near-term item in the current 
environment. 

S ummary 

The central theme of this section has centered on the concept 
of distributed processing. Without some form of CPU waiting time 
utilization, extensive display operations are not feasible in the 
AFICCS system. To aid in the implementation of such a feature, 
the following concepts have been introduced: 

a) Periodic programmed interrupt-tests via DSKACC or COPS; 

b) Time-sharing techniques using the COPS program; 

c) Distributed processing techniques to make full utilization 
of the power of the display processor; and 

d) Buffer management techniques to further enhance distributed 
processing operations. 

The recommendations fit within the structure of the existing 
AFICCS display system and do not constitute a major redesign. 




SECTION IV 

LONG-RANGE RECOMMENDATIONS 


SYSTEM COMPONENTS 

An orderly definition of system functions and requirements is 
of paramount importance in the acquisition and implementation stage 
of any display system. Current and anticipated functional require¬ 
ments should be the prime motivation in the acquisition of any 
display hardware. The wide range of display equipment now available 
permits intelligent selection of display stations and consoles 
according to intended functional requirements. 

Selection criteria to be considered include the following: 

a) Complexity of desired graphics capabilities; 

b) Degree of required man/machine interactivity; 

c) Availability of manufacturers supplied software; and 

d) Operational requirements. 

CRT display devices range from simple alphameric to complex, 
multicolor graphic display consoles. Whereas alphameric displays 
permit only the viewing of preformat ted symbolic data, similar to 
a typewriter, graphic displays provide for both symbolic data and 
line (vector, curve) data. The associate cost scale may range from 
the $1,000 category for simple alphameric devices to $500,000 for 
sophisticated graphic display stations. Consequently, the need for 
an analysis of the functional requirements becomes apparent. 

Man/machine interaction with displays may range from simple 
monitoring (no or little interaction) to a continuous dialog, where 
man and machine interchange information and the path of follow-on 
action is determined dynamically. The anticipated degree of this 
interaction should be a leading factor in the selection of displays. 

In the past, displays were considered and purchased simply as 
hardware items; little or no supporting software was provided by 
the manufacturer. The same condition existed for computers in their 
earlier stages of evolution; however, at this time, little or no 
consideration would be given toward purchase of a data processing 
system without supporting software, Similarly, displays require 
programming and consequently, the programming facilities and 
aids provided with the displays should provide a role in their selection. 
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Rarely have displays been an integral part in the initial 
design of a data processing system. As in AFICCS, they usually 
were added after the system became operational, resulting in their 
partial incompatibility and inefficient utilization. It is therefore 
recommended that if displays are to be utilized, they should play 
an integral part in the initial system definition. 

SOFTWARE CONSIDERATIONS 

Fundamental design criteria for display software consists of 
the attainment of the following objectives: 

a) Utility programs must provide control over all 
features of the display; 

b) The basic software must be programmer oriented to permit 
the relatively easy implementation of higher level 
application programs; and 

c) Functional application programs must be user (non- 
programmer) oriented and interact significantly with the 
primary functional requirements. 

To achieve these objectives most easily, a hierarchical or 
multi-level structure in display program design is desirable. In 
this fashion, the lowest level software would comprise the basic 
building blocks upon which higher level programs are built. The 
software levels required for an interactive display environment may 
include the following: 

a) Basic Hardware Service Routines; 

b) Buffer Management Utilities; 

c) Application programming facilities; and 

d) Functional user programs. 

The hardware service routines provide the basic elements to 
the operation of the displays and higher level programs. Their 
functions include CRT refreshing, interrupt processing, data trans¬ 
mission and in general, all detail control associated with the 
features of the display console. (In the existing AFICCS display 
system, the N-mode program generally performs this type of operation) 


* 
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Efficient buffer management techniques are of extreme 
importance in display operation, since it is desired to use the 
features of the display to their fullest potential. In general, 
buffer management includes the following operations: 

4 

a) Allocation of CPU core memory for display buffer 
construction; 

b) Retrieving display strings or blocks from secondary 
storage; 

c) Allocation, maintenance and modification of multistring 
display frames; 

d) Allocation of display processor core and transfer of 
frames from the CPU to the display processor; and 

e) Allocation and loading of display programs. 

This category of display software may be considered one level above 
the elementary routines with their combination forming the basis to 
the construction of application programming aids. 

v A compiler-type display language should be the core of the 

programming facilities for modern interactive displays. It should 
serve as the basic programming tool to the generation of user 
t programs. As such, it must provide for the easy construction of 

symbolic display messages and permit the addressing and modification 
of detail components (subpictures) of a display frame. 

SUMMARY 

In view of long-range planning, such as conversion to third 
generation equipment, AFICCS has the opportunity to avoid (.existing) 
problems that prohibit efficient use of displays. Hence, the 
following recommendations are presented. 

a) Plan the display system as an integral component of the 
data processing system; 

b) Utilize the inherent characteristics of the display 
devices to their maximum; and 

c) Provide comprehensive programming tools which lead to 
efficient utilization of the available display components 


* 
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APPENDIX A 

GRAPH GENERATION CAPABILITY 


A general capability for the graphic representation of numeric 
data has been produced at the AFICCS Support Facility. The capa¬ 
bility was designed to produce comparative line graphs or scatter- 
grams of numeric attributes of any AFICCS serial tape file. The 
program is controlled completely by user interaction on the BR-90 
console; the only 1410 console operator action required is the 
initial loading of the display system^ and the mounting of the 
input tape. 

FUNCTIONAL DESCRIPTION 
Input Selection 

Selection of the desired fields to be graphed and the specifica¬ 
tion of other record qualification criteria is entered on-line on 
the BR-90 console. The user specifies the following: 

Record selection parameters (maximum of four) which 
c onjunctively determine if a given record qualifies for retrieval. 

Each parameter is identified by: 

a) Relative location in logical record; 

b) Field length; 

c) Value. 

Coordinate selection parameters (two) which determine the numeric 
fields to be plotted as the (x,y) coordinates. 

Each coordinate parameter is identified by: 

a) Relative location in logical record; 

b) Field length. 


MTR-857, 


A BR-90 Operating System. 
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Scale Selection 


Two methods are available: 

a) Scale limits computed from qualified input; and 

b) Scale limits (minimum, maximum) determined by user. 

If the user does not specify minimum or maximum scale values 
for either coordinate axes, they will be determined automatically 
by scanning for the maximal values of the coordinates. (In this 
case, the minimum value; e.g., left end point of both axes, is zero.) 

By selectively determining the extremal values of either axes, 
the user can further subset his displayed data and produce a 
magnification effect. 

Extremal scale values can be specified by up to ten (10) digit 
numbers. 

Any combination of scale selection is allowable. (Example: 
Maximum ordinate value is user specified at 10,000 while others are 
left to be computed.) 

P lotting Options 

At most, two distinct graphs or plots may be displayed 
concurrently. The following combinations are available: 

Single Graphs 

a) Vector Graph (narrow lines); 

b) Point plot; 

c) Average 1 ^; 

d) Sum 1 ^. 


10 


Sums or averages may be computed if more than one data value is 
associated with a distinct x-coordinate. 
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Overlay Graphs 


a) First graph is always narrow vector; 


b) Second graph may be: 


i) Wide flashing vector (same scale); 


ii) Foints (same scale); 


iii) Special character: delta (same scale) 


iv) Wide flashing vector (different scale) 


Display Limits 

A single graph may consist of up to 248 vectors or 249 points 
or special characters (deltas). If more data were qualified, an 
averaging algorithm is used to reduce the data to less than 250 
average values. (If averaging is not desired, sufficient restraints 
should be established to qualify less than 250 records.) 

U nsorted Input Data 

The capability contains a sort routine to produce simple (not 
overlapping) vector graphs for unsorted input data. 


V 


PROGRAM DESCRIPTION 

The capability essentially consists of two distinct programs: 
a 1410 retrieval program and a BR-90 resident display control and 
formatting routine. The capability was implemented under the MITRE 
generated BR-90 Operating System^-! and as such, does not employ the 
CIP/N-mode configuration. 


s 
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The 1410 program component performs the following functions: 

a) Retrieval of qualified tape records and attribute values; 

b) Interim disk storage of qualified data; 

c) Automatic scale selection and scale conversion for 
CRT screen compatibility; 

d) Sorting (if required); and 

e) Statistical operation (sums and averages) . 

CPU/Display communication is conducted in unformatted stream 
mode under control of the Display Operating System. Display frames 
are not transmitted from the CPU to the BR-90; only the data 
pertinent to the construction of a frame is sent. The BR-90 
resident display application routine performs the actual frame 
construction in addition to controlling the operator interaction. 

(Examples of a control cue and the resultant graph are shown 
in the following figures.) 
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Figure 2. Graph Generation Output 



APPENDIX B 

MAP COORDINATE CONVERSION 


Coordinate conversion techniques are required to correlate 
superimposed CRT data with maps projected from background slides. 
Essentially, two projection types are employed by the standard 
geographic reference slides in magazine zero^ G f the BR-90: 

a) Mercator's Conformal Cylindrical - Slides 1 to 81; 

b) Polar Stereographic - Slides 82 to 99. 

This appendix provides mathematical conversion formulas for the 
above projections. 

MERCATOR CONFORMAL CYLINDRICAL 

Transformation from map coordinates (latitude, longitude) to 
rectangular (x,y) screen coordinates is rendered by: 


X « k(A- a o ) + x p 



( 1 ) 


where \ = longitude of point whose conversion is desired; 


♦ s 


latitude of point whose conversion is desired; 


k “ scaling factor (must be computed for each slide); 


X Q = longitude of fixed reference point; 

X 83 screen x-coordinate associated with fixed reference point 
P 

c = slide constant (must be computed for each slide). 



zero is a standard AFICCS feature. 
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Example 


For each map (slide) for which conversion is desired, the 
following constants and reference points should be computed and stored 
in a table. (The computations show below are for Slide 79, The 
World, 105 W to 124 E) : 


S caling Factor (k) 


Determine the screen distance between two parallels of longitude 
(via cursor and cursor coordinate feature). If the distance between 
two parallels is 205 ft units and their separation is 30° (.52 radians) 
then: 


k 


205 8 

.52 


133 

.52 


256 unit 
radians 


S lide Constant (c) 

This constant represents the distance from the bottom of the 
screen (y « 0) to the equator. If the equator is shown on the map, 
then the distance can be measured directly via the cursor; other¬ 
wise, it must be computed from (1) by solving for k. For Slide 79 
the distance was measured and found to be: 

c = 553g. 

Fixed Reference Points (\>>Xp) 


The fixed reference point is usually chosen in the center 
region of the map to reduce distortion by optical irregularities. 

In this case, the reference point was selected as (30°N, 30°E) with 
the corresponding (via cursor) screen coordinates of (1110,777) g. 
Hence: 


A = 30° 
o 

X = 1110 
P 
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Conversion Example 


Assume coordinates 45°N, 90°W are to be converted: 


Then 


A = “"90 = —1,57 radians 

0 = 45° 


x 


256 (-1.57 -.524) + 1110 g = 61 g 


y = 256 In tan(1.177) + 553 g 

= 256(.884) + 553 g =* H15g. 

Consequently, the desired screen coordinates are (61,1115) Q . 

o 


POLAR STEREOGRAPHIC (Northern Hemisphere) 
The transformation is given by: 


7r <p 

x = k tan (—^ — cos (A + Ot) + c^ 


y = k tan (— — —) sin (A+Ot) + c. 


( 2 ) 


4 2 


where A 

0 

k 

c 1 ,c 2 ,ot 


longitude of point whose conversion is desired; 
latitude of point whose conversion is desired; 
scaling factor (to be computed); 
constants (to be computed or measured). 


J 


< 
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Example 


The computations shown below were performed for Slide 88, 

Entire Northern Hemisphere. 

Scaling Factor (k) 

This factor must be computed by solving either component 
equation of (2) for k. A fixed point must be selected to provide 
corresponding values of (X , <f>) and (x,y) . For this slide, k was 
found to be 553g. 

C onstants 

The pair (c^,c2) represents the screen coordinates corresponding 
to the North Pole; in this case (754,761)g as measured by cursor. 

The constant a represents the angular displacement of the 
central meridian from the screen x-axis, measured in a counter¬ 
clockwise direction. (This constant was found to be 15° for all 
polar stereographic slides in magazine zero). 

C onversion Example 

Assume coordinates 30N, 30E to be converted: 


X = 553 g tan (-^ - 15°) cos (30° + 15°) + 754 g = 1200 g 
y = 553 g tan(—£ - 15°) sin (30° + l 5 °) + 761 g = 1205 g 


REMARK 

While the set of constants needs to be computed only once for 
each slide, differences in optics and slide mounting between BR-90 
consoles necessitate the computation of separate constants for 
distinct display consoles. 
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APPENDIX C 

GRAPHIC MANIPULATION 


In modern applications of interactive graphic displays, it is 
common to perform various operations on individual components 
(subpictures) of an existing display string (frame) . The general 
objective of such operations is the construction of a new picture 
from an existing frame with a minimum of effort and high degree of 
versatility. Typical examples of such procedures include: 

a) Construction of complex pictures from simple components 
(i.e., construction of electrical network diagrams from 
basic subpictures showing resistors, capacitors, etc.); 

b) Changing sections of an existing display frame to 
indicate occurrence of a dynamic process (i.e., change 

in disposition of forces with respect to a background map); 

c) Enlarging a display or selected components (zooming or 
scissoring). 

In addition to sophisticated buffer management, various 
mathematical display string manipulation techniques are required 
to perform operations of this category. All of these mathematical 
functions result in transformation of the CRT screen coordinates 
associated with the vectors or points constituting a frame or sub- 
frame. Two categories of elementary transformation are presented 
with the objective of stimulating interest for application to a 
command and control environment13 # 

RIGID TRANSFORMATIONS 

Preliminary Assumptions 

a) The three dimensional Cartesian coordinate system will be 
chosen as follows. The CRT screen will be the xy plane, as is the 
usual fashion, and the z axis will be normal to the screen toward 
the observer. It should be noted that this coordinate system is 
right handed. 


j 




13 


These techniques have been employed for BR-90 demonstrations at 
the AFICCS Support Facility. 
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b) The object to be displayed will be assumed to exist in 
3-dimensional space with some predefined configuration (i.e., we 
are given a set of points (x,y,z) which define the object). For 
our purposes, the z coordinates will be less than zero, since the 
object to be displayed will be considered to be 'behind* the screen. 

c) Once we have chosen some point (xQ,y 0 ,z 0 ) as a basis of 
projection (here z Q is also less than zero), we can project a point 
(x,y,z) from the base point (xo,y 0 ,z 0 ) onto the screen yielding some 
(x 1 ,y',0). The ordered pair (x*,y') will be the desired CRT 
screen coordinate. 


R igid Motions 

The following formulas govern rigid motion (translation, 
rotation) in space: 


I) 


Translation of a point (x,y,z) by a displacement 


X' 

X 


6 x 

Y' 

Y 

+ 

6 Y 

Z' 

Z 


6z 

L _• 

U. -J 


_j 


( <5 x, 6 y, 6 z): 


( 1 ) 


II) Rotation of a point about a coordinate axis (all rotations 
are assumed to be clockwise): 

a) Rotation of a point (x,y,z) by an angle a about the 
x axis: 


r i 





I -1 

i r 


l 

0 

0 


X 

Y’ 

a 

o 

COS Ct 

sina 


Y j 

I 

Z' 


0 

—sinct 

cos ct 


Z J 

__ 






-1 


( 2 ) 


t 




32 













b) Rotation of a point (x,y,z) by an angle /? 
about the y axis: 



X' 

I 

cos/? 

0 

sin ft 


Y' 

1 

= 

0 

1 

0 


Z' 


—sin/S 

0 

cos 


X 

Y 

Z 


(3) 


c) Rotation of a point (x,y,z) by an angle ot 
about the z axis 


X’ | 

i 

Y* I 
z' ! 


— 



r " 

i x 

j 

cos ot 

sin ot 

0 

—sin ot 

cos Ot 

0 

i 

! Y 

0 

L 

0 

1 

-! 


(4) 


Observations 


For display purposes, in light of assumption (1), the equation 
of the plane of projection will simply by z = 0, The above ideas 
were implemented in a BR-90 program which displays a projection of 
a 3-dimensional cube which can be translated or rotated, A table 
of sines was stored in the BR-90 core for use in equations (2) - 
(4). The cosine was computed by the fact that cos 0 * sin (90 - 0 ), 
Translation was considered along the x and y axes only. Also, the 
point of projection was taken to be at an infinite distance away 
on the z axis. 


DATA SCALING 


This process is the mapping of one rectangular area onto 
another rectangular area. Data scaling is required for the conver¬ 
sion of any numerically oriented input for particular CRT displays. 
Immediate applications are: 


< 
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a) Superimposition of background map data with CRT data; and 


b) Zooming (expansion of selected portions of CRT screen to 
the full screen). 

The following notation will be used for the data scaling 
function: 

a) Let A be the rectangle to be projected, while B is the 
rectangle onto which images of rectangle A are projected; 

b) Let (x^,yp be the coordinates of lower left corner of B; 

c) Let (* 2 ^ 2 ) the coordinates of upper right corner of B; 

d) Let ( u ^> v ]) he the coordinates of lower left corner of A; 

e) Let (u^jV^) be the coordinates of upper right corner of A; 

f) Let (u,v) be the point of A which is to be projected onto 
B at point (x,y) . 


( u 2’ v 2) 


(x 2 ,y 2 ) 

_ ! 

(x,y)* | 

i 


and 


(u,v) 


B 


CRT Screen 
















The following linear functions can be used for data scaling: 


x = 


(u - Uj) (x 2 - Xj) 

<u 2 ■ u l> 


+ x^; and 


_ (V - v t ) ■ (y 2 - yj > 
y ( v 2 " v p y l 


Zooming 

Zooming provides for the expansion of selected portions of the 
CRT screen to the full screen size in such a manner as to preserve 
angles (conformal) and relative distances. The above equations 
are applicable and for the BR-90 reduce to: 




x 


I777 8 l u ~ u l l 

d 


y 


1777 8 | v - *1 

d 


where d = max ( | u 2 “ u i 
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